The present invention relates generally to medical imaging systems, and more particularly, to a system for dynamic generation of a single interface for a medical imaging scanner to allow a user to review and edit configuration parameters of the medical imaging scanner from the single web-based interface.
Medical imaging scanning devices, such as computer tomography (CT) systems, x-ray systems, magnetic resonance imaging (MRI) systems, positron emission tomography (PET) systems and the like, are defined by a number of subsystems that control the major functionalities of the device. For example, some subsystems of an x-ray scanner include an x-ray generator, a table positioner, a system control, and an operator console. These subsystems may be further subdivided into subsystems of the subsystem, or micro-subsystems. For example, the operator console may include multiple control interfaces such as keyboards, mice, and touch-screen monitors wherein each has multiple outputs or inputs or multiple functions and therefore is considered an individual subsystem of the operator console subsystem and has specific software dedicated to interpreting user input therefrom. This amalgamation of subsystems results in a distributed overall system hardware configuration. Due to this distributed configuration, the overall x-ray scanner functionality is commonly achieved using distributed object oriented infrastructure components as a middleware interface between the specific software running the various scanner subsystems or between the subsystems and external user applications.
One type middleware implementation that is commonly selected in medical imaging scanners is Common Object Request Broker Architecture (CORBA®). CORBA® is a registered trademark of Object Management Group, Inc., of Farmingham, Mass. A CORBA® architecture is a platform-independent architecture that facilitates the interaction of computer applications that are not readily capable of interaction. A program based on the CORBA® architecture will be able to communicate with other applications regardless of computer manufacturer, operating system, programming language, and network. CORBA® applications are composed of “objects” or individual units of software that can be combined to develop functionality. An “object” is generally defined as a programming component that can be used to build arrangements of variables and operations therein. Applications built with this “object-oriented” programming are developed in a block-by-block or “object-by-object” fashion. These arrangements can be logically grouped into “structures” or “classes.” Each “class” can be designed to perform a specific operation or operations on data passed to it by another class.
Typically, in object-oriented programming, each object includes an “interface.” The “interface” for each object is the syntax of the object that allows other objects to invoke the object. A first object that wishes to invoke an operation by a second object uses the interface to “call” the second object, and pass on the arguments on which the operation must be performed. When the operation is complete, the interface is then used to collect the results for forwarding to the desired destination; typically, back to the first object that requested the operation.
The distributed object oriented infrastructure components provide a means whereby the interface definition is independent of programming language. Independence is achieved by mapping the interface to multiple programming languages such as C, C++, and Java®. Java® is a registered trademark of Sun Microsystems, Inc., of Palo Alto, Calif. This separation of the interface and the execution is a chief benefit of implementing distributed object oriented infrastructure components. In a medical imaging device, distributed object oriented infrastructure components are used to enable the interaction of the various subsystems of the medical imaging device. As such, the distributed object oriented infrastructure components need to access configuration data necessary for the proper running of the subsystem. This configuration data is stored in configuration files which are initially defined and used during the running of the system. During the servicing of such an x-ray system, a service engineer uses an interface to access the configuration data. Should the engineer or other service technician need to change or otherwise update the configuration data, the engineer must use a second and separate application that provides a second and separate user interface specifically designed to facilitate editing of the configuration data. That is, a second user interface is required for the user to change the configuration parameters and communicate those changes to a distributed object oriented infrastructure component for implementation.
For example, a service engineer, when servicing a scanner, must first review the data in one user interface and then switch to a separate user interface to edit the data. This requirement of a second and separate user interface to permit the service engineer to change configuration data creates a servicing and/or maintenance process that is arduous, time consuming, and error prone.
The process of changing the configuration data can be arduous because the service must switch repeatedly between the “viewing” interface and the “editing” interface. Furthermore, by requiring a separate user interface for editing configuration data, the service engineer is effectively tethered to the system. That is, while the “viewing” interface is typically displayable in a web browser and therefore, can easily be made accessible remotely, the “editing” interface is not as readily accessible from remote locations. That is, while the “viewing” web browser interface is readily compliant with internet compatibility standards, the “editing” interface is not necessarily compliant with those standards. Therefore, the service engineer is effectively tethered by the “editing” interface to a local proximity of the medical imaging device being serviced.
Additionally, the process of changing the configuration data is susceptible to error because the imposition of a second and separate interface for editing configuration parameters raises the probability of human error. For example, the service engineer is more likely to enter erroneous configurations or enter the correct configuration in an incorrect area when switching from the review interface to the separate edit interface. Errors in configuration data can cause the medical imaging device being serviced to operate improperly or not at all. In such a case, a second servicing is typically required to remedy the configuration error. These repetitive service calls can be extremely costly in both time and resources. In addition, the servicing downtime for the medical imaging scanner can be an impediment to the efficient and effective practice of medicine.
It would therefore be desirable to have a system and method capable of dynamically generating a single user interface for display and entry of medical imaging configuration parameters.